Team Recovery

Preface

This note gives the reader an idea of how I work and think – it demonstrates how I took on a new role and made a success of it.

My approach for a different employer and role would be adjusted as necessary.

Introduction

My new company had a number of Agile eServices teams that handled the development and support of web based applications (in-house written) and packages (e.g. Interwoven CMS).

Each major zone (North America, South Pacific (Australia), South Africa, Europe (UK)) had a regional eServices team providing support and development resource for the applications unique to that zone.

In addition there was my Global Agile eServices team (UK based) that developed and supported global applications (i.e. the ones used in more than one zone).

The regional teams were typically four or five strong, my Global team consisted of onshore development / test / 3rd line support team and more development and support staff offshore totalling about twenty five staff.

The Global eServices team's responsibilities covered:

• Development of new applications, web sites, portals etc.
• Implementation of packages
• Support of the above including enhancements and upgrades.
• Developing, owning and communicating the eServices development standards and methodology to the regional teams.

The user base of the applications was truly global and hence the support of the applications necessitated a 24x7 support rota.

The applications were written in-house in .Net and Java. The main package was our CMS – Interwoven Teamsite (know HP Teamsite) – it supported all the company's global web sites as well as a large number of internal sites – the global intranet. Several hundred people were trained to submit content and the internal audience was thousands.

When I joined the team had been without a manager for a number of months – the previous manager had resigned from the post because of stress.

First Steps

When I joined I knew the first thing I had to do was understand the team, get their respect and get the basics working properly.

I interviewed each team member to get their background (walking through their job description and last appraisal) and got their thoughts on what was right and wrong with the team.  I also gave them a copy of my c.v. so they knew my background.

There were some basic issues within the team relating to the support rota, overtime payments, holiday, allocation of trouble tickets etc.

The processes around these were not written down and hence there was not a consistent approach. This was proving quite divisive to the team - so early on we defined and wrote up simple processes for managing these areas (including example scenarios).

We also created the necessary tools (typically spreadsheets with VBA macros) to support the processes. The processes were reviewed and approved by the team and held on our Intranet.

Becoming Efficient

The pattern of recognising problem areas and then writing simple processes and creating tools to bring the problem areas under control was repeated. I also brought in management information as a tool to help us improve each area – it allowed us to establish a baseline and then set targets and improve.

The following are some of the areas we focussed on:

Workload / Resource Allocation

When I joined there was an inadequate system for tracking active work and no defined processes for estimating or the allocation of resource – this lack of control meant the team was over allocated. This resulted in the team working really hard to try and get all the work done but inevitably they would fail and miss deadlines – not at all good for morale or for our customers.

We decided to divide the work  into three categories:

1. Major projects
2. Enhancements (between 5 and 30 days)
3. Minor changes (less than five days).

The volume of work was large – there were typically forty or so projects / enhancements active or coming up at any one time.

I introduced formal processes for resource allocation - external projects used them to request resource from the team.

We formalised our estimating and set up a sophisticated spreadsheet that tracked all work. Each team member was given a view of the spreadsheet – allowing him to see exactly what time he should spend on each piece of work he was assigned to.  Other views allowed us to confirm allocations to the PMs and get a picture of forward load that we could discuss with our offshore partners and the regional teams.

A process was also defined detailing what should happen if a piece of work was likely to overrun. Put simply the process said to inform me and give me some rationale as to the cause - so I could sort out the situation with the PM. What I didn't want to happen was for the individual either to work excessive overtime or rob Peter to pay Paul – that would just give us more problems.

The team's timesheets mimicked the spreadsheet and allowed us to track that they were working as requested.

The processes took a while to bed in but because we explained in the process why they were needed and gave examples of how they should be used I think we minimised the time this took.

We handled the transition for some of the more senior users to the new method of working rather more gently that we did for the project managers but eventually all accepted the processes.

These measures meant we could track work and manage each team member's workload avoiding the demoralising over allocation /overwork / missed deadlines vicious circle that had gone before.

The changes to the engagement process also meant we gained early sight of projects allowing us to plan resourcing and adjust the team's profile to accommodate demand, either by cross training, use of contractors or use of offshore. We gave the different pieces of work different statuses ('coming up' , 'gone away', 'to be scheduled' ,' active' and  'complete') to help with this.

Tools and Skills

Another problem was that historically the regional and global teams had used a fairly large number of tools (from editors to custom controls to web servers) to support their work and there was no standardisation across the teams.

We managed this by cataloguing all the tools and agreeing to give each a green, amber or red designation.

• Green – can be used with no restrictions.
• Amber – can be used but requires architectural approval – these were either emerging tools or tools that we were sometimes forced to use e.g. because of package dependencies.
• Red – tools that were used but that should no longer be used other than for maintenance.

We also defined team members' skills (1-5) against the key technologies / tools and introduced the idea of increasing their skills as part of their objectives. This grading assisted with resource allocation and forward load planning.

In addition we defined a process for the team to gain accreditations. It was agreed that the company would pay for exams and books and give a couple of days off to prepare for and take an exam. To keep costs down the team member was expected to study in their own time. The typical expectation being that they gain accreditation in subjects they were already relatively competent in. We didn't offer to fund the expensive courses offered (attending courses for .Net and UML certifications is not mandatory and for our CMS certifications we gained a waiver).

Skills profiles (and improvements made during the year) were reviewed at appraisal time.

These steps let to a more consistent approach within the global team and also the regional teams around the world – it also improved motivation and was another step towards becoming a really professional team.

Development Processes

We recognised that the development processes in use by the teams were ill-defined. We therefore researched tools (e.g. Stylecop, FXcop) and wrote standards and simple processes to formalise key aspects of each of our technical development processes. As you would expect the standards referenced industry best practice and so were typically short. The use of supporting tools was mandated and reviews using the standards and their associated process and checklist then became a formal part of the development process.

Typically standards for a particular area consisted of:

• The standards document itself outlining best practice and referencing tools and external sources.
• The processes to use the tools
• The process to follow to carry out a review
• The checklist to be used for the review

How often reviews should happen, what percentage of code should be reviewed etc. was decided at the start of each project and written in to the QA section of the PID - it depended on a number of factors, mostly relating to risk and experience levels.

Over time we moved to more automation of some of these processes for example we used FXCop and Stylecop to analyse code and give quantitative measures of its conformance to standards.

This formalising of QA processes improved the quality of the applications and helped identify training needs.

To support the standards individuals were picked to write guideline documents that described our recommended approach to some of the more complicated aspects of development such as security, file transfers, eMail integration etc.

We also formalised the use of UML in the analysis and design phases – rolling out IBM's Rational XDE tool to all the regions and incorporating RUP principles and deliverables into the company's project management / development methodology.

Support

The teams supported a large number of apps and once again there was little monitoring of the work being done.

Reports from the problem (trouble ticket) management tool were inflexible and not fit for purpose so we developed and ran a daily extract to an OLAP that allowed us to easily produce pivot tables and graphs in Excel illustrating:

• Which apps were causing the problems
• The performance of the teams and individuals in resolving TTs (trouble tickets)

The tables/graphs could be sliced and diced in Excel using all the basic criteria (application, team, team member, severity of problem, resolve time, wait time, no of 'hops').

We managed the teams' performance using the point in time data and also built up the data in the OLAP so we could examine trends over time.

This allowed me to set the team (on and off-shore) targets and monitor against them and the regional team leaders did the same for their teams. It also allowed us to identify problem applications and initiate work to improve them. Finally the trends reporting allowed us to prove our success.

Reporting

With all the processes and tools in place it was easy to produce a management information pack for my boss that tracked the key aspects of the regional and global teams' work and performance.

Final Stages

We had been working as a split team. On development projects the UK and satellite regional teams provided the technical leads while most construction was outsourced to India.

The company expanded it's captive centre in India and all the global team's work including support was transitioned there. The regional teams were left in place. The fact that we had defined processes by that time expedited the transition and it was a success.

With my role moving to India, the company kindly offered me a project management role which I accepted – so I went on to run a variety of projects some of which used the India based team.

Conclusion

This was a tough period for the team - in the early stages in particular. Time was spent fire-fighting due to the lack or organisation and this meant it was difficult to make quick progress with defining and implementing the processes that the team really needed.

The team did however manage it and it was satisfying to successfully transition the team's work to India with a full set of processes resulting in few problems during or following the transition.

It was disappointing that the professional team that had been created was disbanded – it was full of motivated and enthusiastic individuals – all with their own character traits! But on a positive note I think that change in people's lives is often good for them and everyone on that team successfully found a new role either within the company or outside.